You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.
External trusts
When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest.
Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features. For information about enabling advanced features, see To view advanced features.
In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the trusting domain.
For more information about how to create an external trust, see To create an external trust.
To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier (SID) filtering on all new outgoing external trusts by default.
By applying SID filtering to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.
When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID Filtering and how to further mitigate an elevation of privilege attack, see Using Security Identifier (SID) Filtering to Prevent Elevation of Privilege Attacks at the Microsoft Web site. (http://www.microsoft.com/)
When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which it was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.
In a similar fashion, outgoing external trusts created from the trusting domain use SID filtering to verify that incoming authentication requests made from security principals in the trusted domain only contain SIDs of security principals in the trusted domain. This is done by comparing the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID.
SID filtering ensures that any misuse of the SIDHistory attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.
The SIDHistory attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add SIDs from an old user or group account to the SIDHistory attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account.
If domain administrators could not use the SIDHistory attribute in this way, they would have to track down and reapply permissions for the new account on each network resource that the old account had access to.
If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.
After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SIDHistory attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest.
SID filtering neutralizes the threat of malicious users in the trusted domain from using the SIDHistory attribute to gain elevated privileges.
SID filtering on external trusts can affect your existing Active Directory infrastructure in the following two areas:
When SID filtering is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.
If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filtering will have a major impact on your access control strategy.
Because universal groups must adhere to the same SID filtering guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain.
If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication requests made from members of that universal group will be filtered and discarded.
Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted domain users was created in the trusted domain.
Although it is not recommended, you can disable SID filtering for an external trust by using the Netdom.exe tool. You should consider disabling SID filtering only in the following situations:
Only domain administrators can disable SID filtering. To disable SID filtering for the trusting domain, type the following syntax at a command-prompt:
Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd
To enable SID filtering, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.
You can enable or disable SID filtering only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filtering in the trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax.
Notes